home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
-
- Reported by John Linn/Geer Zolot Associates and Sam Sjogren/TGV
-
- Minutes of the Common Authentication Technology Working Group (CAT)
-
- The Common Authentication Technology Working Group (CAT) met for two
- sessions at the Columbus IETF. The primary Agenda item was integration
- of security features into FTP, a topic for which Sam Sjogren is acting
- as task leader and on which Steve Lunt has generated a working document
- which will shortly be released as an Internet-Draft. Additional
- discussion topics were the advancement status of currently active CAT
- Internet-Drafts (GSS-API, GSS-API C bindings, and Kerberos V5), and a
- working proposal by Ted Ts'o for a CATS stream-oriented protocol overlay
- to be used in conjunction with GSS-API.
-
- Status Of Specifications
-
- The CAT Internet-Drafts have been pending administrative action for some
- time, and an action plan was evolved for their advancement
- recommendation. An updated Kerberos V5 specification was produced by
- Cliff Neuman; comments received from its review list by April 10th will
- be reflected in an Internet-Draft to be issued by April 17th. Primary
- late-breaking changes include added detail on an encrypted timestamp
- preauthentication type, and a new message type for credential exchange
- when proxies are being provided to an end server.
-
- Concurrently with the Kerberos specification review, an advancement memo
- will be prepared for the set of Internet-Drafts (GSS-API, GSS-API C
- bindings, Kerberos V5). Intended follow-on documents will include a CAT
- mechanism definition (with token format) based on Kerberos V5. It was
- determined that use of the mechanism tagging recommended in GSS-API
- Appendix B should be adopted as mandatory, and message stream facilities
- were strongly desired within GSS-API mechanisms in order to satisfy FTP
- functional and integration requirements; a new appendix to the GSS-API
- specification has been drafted and distributed to the CAT mailing list
- codifying the results of this discussion.
-
- CATS Stream Protocol
-
- The CATS proposal, presented by Ted Ts'o, was engendered by a desire to
- provide prospective protocol integrators with a subprotocol
- specification for security, along with a stream-oriented API. An
- explicit CATS goal is that it be implementable quickly and without
- kernel modifications (unlike, e.g., IP- level security). CATS presents
- an alternative, generic form for protocol integration, contrasting with
- the protocol-specific integration being employed in Telnet options and
- FTP commands. Submission of a revised CATS specification as an
- Internet-Draft is planned.
-
- In evolving CATS, Ted observed that the status of the tagging scheme in
- GSS- API Appendix B as a recommendation to mechanism designers led to
-
- 1
-
-
-
-
-
- undesirable ambiguity, and suggested making it mandatory; this
- suggestion was adopted and would be integrated into the Kerberos V5
- implementation. Among other discussion, it was suggested that the CATS
- protocol be extended in order to exchange preamble tokens in advance of
- context establishment for mechanism type negotiation, and this prospect
- will be examined.
-
- FTP Security
-
- Sam Sjogren began the FTP part of the meeting by describing the goals
- for the FTP security work, as initiated at a BOF during the previous
- IETF and to be continued under the CAT Working Group framework. Support
- for authentication, as well as integrity verification and privacy, via
- any of a number of different mechanisms will be provided by this work.
-
- Steve Lunt presented his proposal for extensions to the FTP protocol
- (additional commands) to implement the security goals; he intends to
- make an FTP security implementation publicly available. An overhead
- presentation supplemented the draft that had previously been posted to
- the Group's mailing list. Lively discussion occurred during and after
- this presentation, to the point that an additional evening meeting was
- scheduled to continue the discussions. The resulting FTP security
- discussions were quite fruitful, both in terms of providing feedback for
- improving the draft proposal for FTP as well as fine tuning the GSS-API
- requirements and specifications. It was decided that the case of a
- three-party FTP interaction is sufficiently complex and rarely enough
- used that specification of how to do it securely will be deferred,
- probably to a separate document to be produced later.
-
- Once peer entity authentication has been completed (and a session key is
- available), the proposed FTP security approach protects all subsequent
- FTP commands for at least integrity (encapsulation of base-64 encoding
- of gss_seal() output within MIC command), and optionally for
- confidentiality as well as integrity (encapsulation within ENC command,
- gss_seal() conf_flag TRUE). It was observed that underlying GSS-API
- mechanisms must represent and protect the conf_avail flag value and
- other service availability indicators within their tokens to prevent
- active attacks; the to-be-written ``Kerberos Vn for GSS-API'' and other
- mechanism design documents will describe how this protection is
- provided. (These indicator protection requirements apply independently
- of whether GSS-API is employed.) To protect against active attackers
- corrupting a data or control stream by changing the order of data or
- commands in the stream, protection via sequence numbers or some other
- such technique must be provided by the FTP security standard or the
- underlying mechanisms.
-
- Given that the FTP control connection is a Telnet stream, questions
- arose about the rationale for not using the Telnet authentication option
- as an approach for FTP. Steve cited two reasons: (1) because the Host
- Requirements RFC precludes use of Telnet options on the FTP control
- connection, and (2) because of a desire to provide data integrity, which
- Telnet security does not offer.
-
-
- 2
-
-
-
-
-
- There was discussion of the fact that no facility was exposed at the
- level of the FTP security commands for negotiating the type and strength
- of cryptography to be used for data protection. However, it was
- recognized that such features can exist within underlying mechanisms yet
- remain transparent at the level of FTP. The ordering of USER and AUTH
- commands will be made such that an FTP server may make a decision on
- what authentication and encryption mechanisms are acceptable based on
- who the user is.
-
- Kerberos ticket granularity and naming issues were discussed. For
- Kerberos V4, the form of a target FTP server's name should be
- ``ftp.<simple-host>'', and for Kerberos V5,
- ``ftp/<domain-qualified-host>''. It was noted that use of different
- target names for different server processes within a host is not
- primarily an access control measure, but does permit the servers to run
- in different protection domains (as might be desirable for an FTP server
- available to casual remote users).
-
- Areas to be revised in the FTP draft based on discussion include:
-
-
- o Additional discussion of requirements.
-
- o Approach for transfer of arbitrarily long tokens from client to
- server.
-
- o Alignment of base-64 encoding technique with RFC1421.
-
- o Statements regarding mechanism negotiation (including a statement
- that an FTP server may refuse to accept anything less than suitably
- strong authentication).
-
- o Further work on the data stream protection approach.
-
-
- Attendees
-
- Steve Alexander stevea@lachman.com
- John Campbell jrcamp@nosc.mil
- William Chung whchung@watson.ibm.com
- Stephen Crocker crocker@tis.com
- Dave Cullerot cullerot@ctron.com
- Antonio Fernandez afa@thumper.bellcore.com
- James Galvin galvin@tis.com
- Jisoo Geiter geiter@mitre.org
- Richard Graveman rfg@ctt.bellcore.com
- Frank Kastenholz kasten@ftp.com
- David Katinsky dmk@pilot.njin.net
- Charles Kaufman kaufman@zk3.dec.com
- Stephen Kent kent@bbn.com
- Zbigniew Kielczewski zbig@eicon.qc.ca
- Andrew Knutsen andrewk@sco.com
-
- 3
-
-
-
-
-
- Paul Lambert paul_lambert@email.mot.com
- John Linn linn@gza.com
- James Mahon mahonj@honfsi1.att.com
- Cynthia Martin martin@spica.disa.mil
- Evan McGinnis bem@3com.com
- P.V. McMahon p.v.mcmahon@rea0803.wins.icl.co.uk
- Bob Morgan morgan@networking.stanford.edu
- Clifford Neuman bcn@isi.edu
- Emmanuel Pasetes ekp@enlil.premenos.sf.ca.us
- Christopher Provenzano proven@csi.compuserve.com
- Steven Richardson sjr@merit.edu
- April Richstein amr@tycho.ncsc.mil
- Shawn Routhier sar@epilogue.com
- Jeffrey Schiller jis@mit.edu
- Wolfgang Schneider schneider@gmd.de
- Sam Sjogren sjogren@tgv.com
- Stuart Stanley stuarts@apertus.com
- Bob Stewart rlstewart@eng.xyplex.com
- Stuart Stubblebine stubblebine@isi.edu
- Louisa Thomson louisa@whitney.hac.com
- Klaus Truoel truoel@gmd.de
- Theodore Ts'o tytso@mit.edu
- James Weatherford weatherf@nosc.mil
- Peter Wilson peter_wilson@3com.com
-
-
-
- 4
-